Miha has asked us to post this for him:

Proposed New .D64 Format

This is the proposal for a new D64 file format. The extension should
be changed to D69 or something to avoid mixing with the old format.

Advantages over the old format:
- supports any number of formatted tracks
- supports half tracks
- supports GCR coded tracks
- supports compressed tracks
  RLE decompression is fast, the files remain zippable
  LZW decompression is slower but tighter, also needs some memory
- supports write protection flag (no dos messing necessary any more)
- users can atach info text
- does NOT support multidisk images, as it is not practical from the
  emulator's point of view
- open for future extension

Please email any suggestions to: miha@ferlin.fer.uni-lj.si


[File header]
Offset, Size, Info
     0, 14    sign: "New D64 File", 0, 1A
    14, 2     file type (lo/hi)
              0x0100 = 01.00
    16, 24    user name
    40, 4     offset of info text (0 = no info atached)
    44, 1     contents type
              0 = empty (invalid!)
              1 = 1541 formatted disk
              2..255 = reserved
    45, 1     write protected
              0 = no
              1 = yes
    46, 2     number of track entries
              normal 1541 disk: 88 entries, used entries: 0, 2, 4, ...66, 68
    48, 16    reserved
    xx, 8*n   track entries (n = number of track entries)
    xx, xx    track data (for each track)

[Track entry]
Offset, Size, Info
0, 1    track type
        0 = empty
        1 = simple, decoded sectors
        2 = simple with error info, decoded sectors + read codes
        3 = RLE coded sectors + read codes
        4 = LZW coded sectors + read codes
        5 = GCR, raw 1541 coded data
        6..255 = reserved
1, 1    type data
        type 0: reserved (0)
        type 1,2,3,4: number of sectors in track
        type 5: reserved (0)
2, 2    track data size
4, 4    file offset of track data

[RLE coding]
initial magic byte MB = $BD
initial data = 0
unpacking input -> output
  data <> MB -> data
  MB 01 -> MB, MB = MB + $13
  MB 02 -> MB MB
  MB nn -> nn * last data (nn = 0 equals nn = 256)

[LZW coding]
the coding is similar to GIF coding
4096 dictionary entries
the first 256 entries are byte equivalents
when the dictionary is full it is cleared immediately (no clear codes)

[GCR coding]
the coding is the same as used by 1541 internaly

[New D64 handling strategy]
- the emulator must be able to read all track types
- any track can be saved anywhere within the file
- byte coded tracks are saved in type 2 when changed
- GCR coded tracks are saved in type 5 when changed
- an external utility is provided to pack/unpack/optimize D64 files
